C. REMARKS 



Status of Claims 

Claims 1 , 3-29, and 31 -54 are pending in the application. Claims 2 and 30 were 
previously cancelled. Claims 1, 3, 4, 9-13, 18-22, 27-29, 33-36, 39-43, and 45-49 are 
currently amended. 



Rejection under 35 USC 101 

The Examiner rejects claims 20-28 and 43-48 under 35 USC 101 because the 
claimed subject matter is allegedly directed to non-statutory subject matter. [Office 
Action, p. 2] In the rejection, the Examiner states: 

Claims 20 and 43 are not limited to tangible embodiments. In view 
of applicant's disclosure, specification page 11 and 12, the medium is not 
limited to tangible embodiments, instead being defined as including both 
tangible embodiments (e.g. a floppy disk, a flexible disk, hard disk, CD- 
ROM, or magnetic tape) and intangible embodiments (e.g. acoustic and 
light waves). As such, the claim is not limited to statutory subject matter 
and is therefore non-statutory. 

To overcome the 101 rejection, the claims need to be amended to 
include only the physical component. 

Claims 21-28 and 44-48 are rejected by virtue of their dependency 
on a rejected base claim. [Office Action, p. 2] 

Applicants amend claims 20 and 43 so that the preamble of claim 20 reads "A program 
for recording a messaging session, residing on a tangible computer usable medium 
having computer readable program code means" and the preamble of claim 43 reads "A 
program for participating in a messaging session, residing on a tangible computer 
usable medium having computer readable program code means." Thus, Applicants 
amend claims 20 and 43 to limit the computer usable medium to the tangible 
embodiments of the volatile, non-volatile, and transmission media described on pages 
1 1 and 12, or paragraph 0042, of the specification of the present application. In view of 
the amendments to claims 20 and 43 limiting the claimed subject matter to tangible 
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embodiments, Applicants respectfully request withdrawal of the rejection under 35 USC 
101 as to claims 20 and 43 and as to claims 21-28 and 44-48, which are dependent 
upon claims 20 and 43. 

Lack of Anticipation under 35 USC § 102(e) 

Claims 29-48 are not anticipated by Rust (US Pub 2004/0054728) 

Claims 29-48 stand rejected under 35 U.S.C. §1 02(e) as being anticipated by 
Rust (US Publication 2004/0054728). [Office Action, p. 3] The rejection is respectfully 
traversed in view of the claims. "A claim is anticipated only if each and every element 
as set forth in the claim is found, either expressly or inherently described, in a single 
prior art reference. Verdegaal Bros. v. Union Oil Co. of California, 2 USPQ2d 1051 , 
1053 (Fed Cir. 1987). Furthermore the reference must be an enabling disclosure of 
each and every element as set forth in the claim. In re Hoecksma, 158 USPQ 596, 600 
(CCPA 1968); In re LeGrive, 133 USPQ 365, 372 (CCPA 1962). Because Rust does 
not teach each and every element of claims 29-48 or enable each and every element of 
these claims, these claims are not anticipated, the rejection should be withdrawn, and 
the claims should be allowed. 

Claims 29, 37, 43 

With regards to claims 29, 37, and 43, independent method claim 29, which is 
representative of independent system claim 37 and independent computer program 
product claim 43, with regard to similarly recited subject matter and rejection, reads as 
follows: 

29. (Currently Amended) A method, in a particular client system from 
among a plurality of clients systems enabled to communicate with one 
another in a messaging session facilitated by a messaging server through 
at least one instant messaging channel via a network, for participating in a 
messaging session facilitated through a particular instant messaging 
channel, said method comprising the steps of: 
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controlling output, at said particular client system, to a user 
participating in said messaging session of entries associated with said 
messaging session received via said messaging server from a plurality of 
users participating in said messaging session; and 

in response to receiving a recording indicator for said messaging 
session from said messaging server, adjusting said output at said 
particular client system to distinguish a selection from among said plurality 
of message entries being recorded into a separate log by said messaging 
server, such that said user participating in said messaging session is 
notified when message entries posted by said user and said plurality of 
users are being recorded. 

In the rejection of claim 29, the Examiner states: 

Rust discloses a method in a particular client system from among a 
plurality of client systems (Presenter client 1 1 0 and Attendee client 1 20) 
enabled to communicate with one another in a messaging session 
facilitated by a messaging server (i.e. control server 140) through at least 
one instant messaging channel via a network (e.g. LAN, WAN, intranet) 
for participating in a messaging session facilitated through a particular 
instant messaging channel, said method comprising the steps of (pg. 3, 
par 0029-0030): 

controlling output, at said particular client system, to a user 
participating in said messaging session of entries associated with said 
messaging session received via said messaging server from a plurality of 
users participating in said messaging session (i.e. controls when the 
session is recorded and the name of the session; pg. 3, par 0031 and 
0033); and 

in response to receiving a recording indicator for said messaging 
session from said messaging server, adjusting said output to distinguish a 
selection from among said plurality of message entries being recorded into 
a separate log by said messaging server, such that said user participating 
in said messaging session is notified when message entries posted by 
said user and said plurality of users are being recorded (i.e. message 
indicates audio or visual data which is recorded in separate logs; pg. 4, 
par. 0037-0038 and par. 0040-0041). [Office Action, p. 3] 

Applicants respectfully assert that Rust does not teach or enable each and every 
element of claims 29, 37, and 43 for the following reasons. 
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Rust does not teach or enable controlling output at said particular client system, 
to a user participating in said messaging session of entries associated with said 



messaging session received via said messaging server from a plurality of users 



participating in said messaging session 



Applicants respectfully assert that Rust does not teach or enable controlling 
output, at said particular client system, to a user participating in said messaging session 
of entries associated with said messaging session received via said messaging server 
from a plurality of users participating in said messaging session because Rust does not 
teach a client system participating in a messaging session. When claims 29, 37, and 43 
are viewed as a whole, the particular client system is one of multiple client systems 
enabled to communicate with one another in a messaging session facilitated by a 
messaging server through at least one instant messaging channel via a network. In 
contrast, Rust describes a "collaborative web browsing system" which is defined as 
"allowing a first computer connected to the Web to cause the browsers of one or more 
second computers simultaneously connected to the Web to display certain 
predetermined Web pages or presentation slides as directed by the first computer." 
Rust, paragraph 0007. Rust describes a presenter client and an attendee client 
connected via a network to a control server that detects a browser display at the 
presenter client and directs an attendee client to display the same browser display as 
the presenter client. Rust, paragraphs 0029, 0030. Thus, Rust merely describes that a 
presenter client can direct what is displayed in the browser window of an attendee 
client; Rust does not teach or enable a real-time, two-way conversation between client 
systems as facilitated via an instant messaging channel by a messaging server. 

During patent examination, the pending claims must be "given their broadest 
reasonable interpretation consistent with the specification." In re Hyatt, 21 1 F.3d 1367, 
1372, 54 USPQ2d 1664, 1667 (Fed. Cir. 2000). The broadest reasonable interpretation 
of the claims must also be consistent with the interpretation that those skilled in the art 
would reach. In re Cortright, 165 F.3d 1353, 1359, 49 USPQ2d 1464, 1468 (Fed. Cir. 
1 999). It is the use of the words in the context of the written description and customarily 
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by those skilled in the relevant art that accurately reflects both the "ordinary" and 
"customary" meaning of the terms of the claims; the ordinary and customary meaning of 
terms may be evidenced in dictionaries and treatises. Ferguson Beauregard/Logic 
Controls v. Mega Systems, 350 F.3d 1327, 1338, 69 USPQ2d 1001, 1009 (Fed. Cir. 
2003); Tex. Digital Sys., Inc. v. Telegenix, Inc., 308 F.3d 1193, 1202, 64 USPQ2s 1812. 
In examining claims 29, 37, and 43 with the broadest reasonable interpretation 
consistent with the specification and consistent with the interpretation that those skilled 
in the art would reach, Applicants respectfully assert that the dictionary definition of 
"instant messaging" reflects the meaning customarily given by those skilled in the 
relevant art and that the use of "instant messaging" within the specification is consistent 
with the dictionary definitions. Thus, regardless of whether Rust describes client 
systems, such as the presenter client and the attendee client and a server system, such 
as the control server, within a "collaborative web browsing system", Applicants 
respectfully assert that the "collaborative web browsing system" of Rust does not teach 
or enable an instant messaging channel through which an instant messaging session 
allowing real-time, two-way communication between client systems, is facilitated. 

First, Applicants assert that the term "instant messaging" when used in the 
context of messaging requests in a computer-implemented system, has an "ordinary" 
and "customary" meaning to one with ordinary skill in the art in the area of a computer- 
implemented system. In one example, the Microsoft Computer Dictionary clearly 
defines instant messaging as: 

"a service that alerts users when friends or colleagues are on line and 
allows them to communicate with each other in real time through private 
online chat areas. With instant messaging, a user creates a list of other 
users with whom he or she wishes to communicate; when a user from his 
or her list is on line, the service alerts the user and enables immediate 
contact with the other user. While instant messaging has primarily been a 
proprietary service offered by Internet service providers such as AOL and 
MSN, businesses are starting to employ instant messaging to increase 
employee efficiency and make expertise more readily available to 
employees." Microsoft Computer Dictionary, 5 th Edition, copyright 
Microsoft Corporation 2002, p. 276. 
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Applicants assert that this definition of "instant messaging" clearly shows that there is an 

"ordinary meaning for the term "instant messaging" as customarily used by one skilled in 

the relevant art that includes a service for alerting users when other users are online 

and enabling online, real time bi-directional chat sessions between users. The ordinary 

meaning of "chat" as customarily used by one skilled in the relevant art is 

"real-time conversation via computer. When a participant types a line of 
text and then presses the Enter key, that participant's words appear on the 
screens of the other participants, who can then respond in kind" and one 
example of a chat service is Internet Relay Chat (IRC)." Microsoft 
Computer Dictionary, 5 th Edition, p. 97. 

Thus, an instant messaging channel is the communication link maintained by the 
messaging server between the multiple client systems to enable the client systems to 
communicate with one another online, in real time, in an instant messaging session. 

Next, the specification provides enabling examples for "instant messaging" that 
are consistent with the dictionary definition of "instant messaging." The specification of 
the present application, paralleling the definition in the Microsoft Computer Dictionary, 
describes in paragraph 0014, one example of an instant messaging service is Internet 
Relay Chat (IRC), which "enables an Internet user to participate in an on-line 
conversation in real time with other users. An IRC channel, maintained by an IRC 
server, transmits the text typed by each user who has joined the channel to the other 
users who have joined the channel. An IRC client shows the names of the currently 
active channels, enables the user to join a channel, and then displays the other channel 
participant's words on individual lines so the user can respond." The specification in 
paragraph 0054 describes the messaging server that facilitates multiple instant 
messaging channels through which instant messaging sessions are facilitated between 
multiple client systems. Thus, the specification of the present application provides 
examples of an instant messaging session facilitated by a messaging server through at 
least one instant messaging channel via a network for enabling bi-directional 
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communication between client systems that are consistent with the dictionary definitions 
of these terms. 

In contrast, as previously noted, the collaborative web browsing system of Rust 
does not teach or enable users to communicate with one another, bi-directionally, 
through an instant messaging channel, but only describes a method for one system to 
direct the browser window display on another system. Rust does not describe bi- 
directional communication, but merely describes synching the browser window display 
on one system to that of another system. 

Therefore, in conclusion, Applicants respectfully assert that interpretation of 
"instant messaging" in claims 29, 37, and 43 in view of the dictionary definitions of the 
term is the broadest reasonable interpretation of claims and provides a broadest 
reasonable interpretation consistent with the specification. In addition, Applicants 
respectfully assert that when "instant messaging channel" is interpreted in view of the 
definition of instant messaging, it is clear that Rust's collaborative web browsing system 
does not teach or enable a client system communicating bi-directionally with other client 
systems in a messaging session via an instant messaging channel supported by a 
messaging server. 

Because Rust does not teach a client system communicating with other client 
systems in a messaging session via an instant messaging channel supported by a 
messaging server, Rust also does not teach or enable the client controlling output to a 
user participating in the messaging session of entries associated with the messaging 
session received via the messaging server from multiple other users participating in the 
messaging session. Therefore, Rust does not teach or enable at least one element of 
claims 29, 37, and 43, Rust does not anticipate the claims and the claims should be 
allowed. 
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Rust does not teach or enable in response to receiving a recording indicator for 
said messaging session from said messaging server, adjusting said output at 
said particular client system to distinguish a selection from among said plurality 
of message entries being recorded into a separate log by said messaging server, 
such that said user participating in said messaging session is notified when 
message entries posted by said user and said plurality of users are being 
recorded 

First, Applicants respectfully assert that Rust does not teach or enable in_ 

response to receiving a recording indicator for said messaging session from said 

messaging server, adjusting said output at said particular client system to distinguish a 

selection from among said plurality of message entries being recorded into a separate 

log by said messaging server, such that said user participating in said messaging 

session is notified when message entries posted by said user and said plurality of users 

are being recorded because Rust does not teach a client system receiving a recording 

indicator for the messaging session from the messaging server. The Examiner cites 

Rust, paragraphs 0037-0038 and 0040-0041 as describing "message indicates audio or 

visual data which is recorded in separate logs" and as reading on the elements of in_ 

response to receiving a recording indicator for said messaging session from said 

messaging server, adjusting said output at said particular client system to distinguish a 

selection from among said plurality of message entries being recorded into a separate 

log by said messaging server, such that said user participating in said messaging 

session is notified when message entries posted by said user and said plurality of users 

are being recorded . [Office Action, p. 3] Paragraphs 0037-0038 of Rust read: 

[0037] To start the recording of a collaborative Web browsing session 100, 
the Presenter Client 110, for example, initiates the recording process. FIG. 
2 illustrates one example of an initialization process of the present 
invention. For example, after the collaborative Web browsing session 100 
has commenced, as indicated by step 200, the Presenter Client 110 
applet waits for messages to send to the Control Server 140. In a 
preferred embodiment, upon receipt of the message, the Presenter Client 
110 sends the message to the Control Server 140, as illustrated in step 
215. When the Presenter Client 110 receives the message, it preferably 
examines the message to determine if the message indicates to start the 
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recording process, as shown, for example, in step 220. 

[0038] In a preferred embodiment, after the recording of the collaborative 
Web browsing session 100 begins, the Presenter Client 110 applet 
continues to wait for messages to send to the Control Server 140, as 
indicated in step 225. For example, when recording, the Presenter Client 
examines the messages to be sent to the server. If the message 
represents an audio event, as illustrated in step 230, the Presenter Client 
1 1 0 increments a counter to keep track of the number of audio messages 
sent to the Control Server 140, as illustrated in step 235. This allows the 
Control Server 140 to later verify receipt of the entire set of audio events 
contained in the collaborative Web browsing session 100. 

In addition, paragraphs 0040-0041 of Rust read: 

[0040] When the recording process is initiated, the Control Server 140, in 
a preferred embodiment, begins storing the audio and visual data 
components of the collaborative Web browsing session 100. FIG. 3 is a 
flowchart that depicts an example of the actions that may take place on 
the Control Server 140 during the recording of a collaborative Web 
browsing session 100. In a preferred embodiment, the collaborative Web 
browsing session 100 has already commenced, as illustrated by step 300. 
For example, in step 310, the Control Server 140 waits for messages from 
the Presenter Client 110. When a message is received, the Control Server 
140 preferably determines whether the message is a start record 315 
event, audio data 320, visual data 325, or a stop record 330 event. The 
Control Server 140, in an example embodiment, subsequently processes 
each message depending on its type. For example, each message 
received by the Control Server 140 is written into an event log to record 
the message type and the time the message was received, as shown in 
steps 335, 340, 345, and 350. 

[0041] In a preferred embodiment, a start record 315 event causes the 
Control Server 140 to begin recording the session. For example, upon 
receiving the start record 315 event, the Control Server 140 writes an 
entry into the event log and then the Control Server 140 opens a 
temporary file, as shown in step 355. This temporary file is used to store 
the visual data elements that are being recorded for the session. 

Thus, Rust merely describes that the presenter client 110 sends messages to the 
control server 140, where control server 140 facilitates the collaborative web browser 
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session. Rust, paragraphs 0030, 0031 . The presenter client 110 includes an applet 
that allows the presenter client's web browser to communicate with the control module 
on control server 140. Rust, paragraph 0030. The presenter client 110 may provide a 
control window through which a user selects to record the collaborative web browser 
session. Rust, paragraph 0033. If the user selects to record, presenter client 110 
sends a message to the control server 140 requesting that control server 140 record the 
collaborative web browser session and presenter client 110 begins to count the number 
of audio messages sent by presenter client 1 10 to the control server 140. Rust, 
paragraphs 0037, 0038. No portion of Rust, paragraphs 0037-0038 or 0040-0041 
describes the control server 140 sending an indicator to any client system indicating that 
recording is initiated. 

As to the Examiner's assertion that Rust describes "message indicates audio or 
visual data which is recorded in separate logs", Applicants respectfully note that no 
portion of Rust includes the phrase stated by the Examiner. In addition, Applicants 
respectfully assert that with regard to a "message", the only message described is sent 
by presenter client 1 10 to control server 140. In particular, as to the phrase "When the 
Presenter Client 110 receives the message, it preferably examines the message to 
determine if the message indicates to start the recording process, as shown, for 
example, in step 220" in paragraph 0038, when Rust is viewed as a whole, merely 
refers to the presenter client 1 10 waiting for the user to selection options, where the 
presenter client 110 detects those options as a message and sends the message to 
control server 140; if the message is one indicating that a user has selected to start the 
recording process, the presenter client 110 starts counting each time it sends audio 
data to the control server 140. Rust, paragraphs 0037, 0038, Figure 2. Rust does not 
describe a client system receiving a message from the server indicating that the 
collaborative web browser session is being recorded. Further, Rust does not describe 
control server 140 sending a message to the client systems indicating that control 
server 140 is recording the collaborative web browser session. 
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In view of the foregoing, Rust does not teach a client system participating in 
messaging session via an instant messaging channel facilitated by a messaging server, 
where the client system receives an indicator from the messaging server that the 
messaging session is being recorded. In contrast, claims 29, 37, and 43 teach in_ 
response to receiving a recording indicator for said messaging session from said 
messaging server, adjusting said output at said particular client system to distinguish a 
selection from among said plurality of message entries being recorded into a separate 
log by said messaging server, such that said user participating in said messaging 
session is notified when message entries posted by said user and said plurality of users 
are being recorded . Therefore, because Rust does not teach or enable all the elements 
of claims 29, 37, and 43, Rust does not anticipate claims 28, 37, and 43 and the claims 
should be allowed. 

Second, Applicants respectfully assert that Rust does not teach or enable in_ 
response to receiving a recording indicator for said messaging session from said 
messaging server, adjusting said output at said particular client system to distinguish a 
selection from among said plurality of message entries being recorded into a separate 
log by said messaging server, such that said user participating in said messaging 
session is notified when message entries posted by said user and said plurality of users 
are being recorded because Rust does not teach a client system adjusting the output of 
the entries associated with a messaging session received via the messaging server to 
distinguish the selection of entries being recorded into a separate log by the messaging 
server. The Examiner cites paragraphs 0037-0038 and 0040-0041 as reading on these 
elements and as describing "message indicates audio or visual data which is recorded 
in separate logs." [Office Action, p. 3] As previously noted, paragraphs 0037-0038 and 
0040-0041 describe that a presenter client 110 sends messages to a control server 140, 
and that the message may include a request to record or a request to stop recording. 
Rust does not, however, describe any of the client systems adjusting the way that the 
collaborative web browsing session is output at the client system to indicate when the 
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collaborative web browsing session is being recorded by the control server 140. Thus, 
Rust also does not teach or enable adjusting the output of the message entries within a 
messaging session, at a client system, to indicate those messages being recorded into 
a separate log from the messaging session by the messaging server. In contrast, 
claims 29, 37, and 43 clearly teach that a client system participating in a messaging 
session, responsive to receiving a recording indicator from the messaging server, 
adjusts the output of message entries at the client system to indicate those messages 
being recorded by the messaging server. In addition, Applicants respectfully assert that 
claim 37, as previously presented, clearly teaches that a client system participating in a 
messaging session, responsive to receiving a recording indicator from the messaging 
server, adjusts the output of message entries at the client system to indicate those 
messages being recorded by the messaging server and that claims 29 and 43 are 
amended to clarify this teaching. 

In view of the foregoing, Rust does not teach a client system adjusting the output 
of message entries in a messaging session to indicate those message entries being 
recorded by a message server. In contrast, claims 29, 37, and 43 teach in response to 
receiving a recording indicator for said messaging session from said messaging server, 
adjusting said output at said particular client system to distinguish a selection from 
among said plurality of message entries being recorded into a separate log by said 
messaging server, such that said user participating in said messaging session is notified 
when message entries posted by said user and said plurality of users are being 
recorded . Therefore, because Rust does not teach or enable all the elements of claims 
29, 37, and 43, Rust does not anticipate claims 28, 37, and 43 and the claims should be 
allowed. 
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Claims 30-36, 38-42, and 44-48 

Applicants respectfully assert that because claims 29, 37, and 43 are not anticipated by 
Rust, claims 30-36, 38-42, and 44-48, which are dependent upon independent claims 
29, 37, and 43, are also not anticipated by Rust and should be allowed. 

Claim 31 

Claim 31 reads as follows: 

31 . (Previously Presented) The method for participating in a 
messaging session according to claim 29, wherein said messaging server 
comprises one of said plurality of client systems. 

In the Office Action, there is not a specific rejection of claim 31 , however, in the rejection 
of claim 30(which was previously cancelled), the rejection states "Rust discloses the 
method for participating in a messaging session according to claim 29, wherein said 
messaging server comprises one of said plurality of client systems (pg. 3, par. 0029- 
0030)." [Office Action, p. 3] The rejection appears to refer to the elements of claim 31 . 
Paragraphs 0029-0030, however, merely describe a collaborative web browsing session 
between a presenter client 110 and an attendee client 120 facilitated by the use of a 
control server 140. No portion of paragraphs 0029-0030 of Rust refers to one of the 
client systems facilitating the collaborative web browsing session. In addition, in the 
rejection of claim 29, the Examiner specifically refers to "control server 140" of Rust as 
reading on a messaging server ; there is no indication in the rejection or in Rust how one 
of presenter client 1 10 or attendee client 120 could function as a messaging server for 
facilitating a messaging session via an instant messaging channel between the client 
systems. In contrast, claim 31 , when viewed as a whole, teaches that the messaging 
server that facilitates an instant messaging channel between Therefore, because no 
portion of Rust teaches or enables said messaging server comprises one of said 
plurality of client systems, Rust does not teach or enable each and every element of 
claim 31 and the claim should be allowed. 
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Claims 33, 39, and 45 



Claim 33, which is representative in rejection of claims 39 and 45, reads as follows: 

33. (Currently Amended) The method for participating in a messaging 
session according to claim 29, said method further comprising the steps 
of: 

receiving, at said particular client system, from said messaging 
server, a recording approval request for recording a specified selection of 
entries associated with said messaging session; 

presenting, at said particular client system, a request for said user 
to approve said recording based on said recording approval request: and 

in response to an indication of approval selected by said user, 
transmitting said indication of approval from said particular client system to 
said messaging server. 

The Examiner rejects claims 33, 39, and 45 based on paragraph 0037 of Rust. Rust, 
paragraph 0037 (previously cited in full) when read in view of the Rust as a whole, 
describes that the presenter client 110 applet waits for messages to send to the control 
server 140 and that one of those messages may indicate the user at presenter client 
110 has selected to start the recording process. Rust does not, however, describe that 
the particular client system receives a recording approval request from the messaging 
server and transmits an indicator of approval to record to the messaging server. In 
addition, Rust does not teach a client system receiving a request from a messaging 
server, presenting the request to the user at the client system, and responsive to 
receiving an indication that the user approves the recording, transmitting the recording 
approval to the messaging server. In contrast, claims 33, 39, and 45 are amended to 
clarify that (1) the particular client system receives a request, from the messaging 
server, for the user to approve the recording of a specified selection of entries; (2) the 
user is presented with an option to approve the request by the messaging server to 
record the entries; and (3) responsive to a selection by the user indicating approval, an 
indication of the approval is transmitted to the messaging server. The specification 
shows one example of a recording approval request, as prompted by the messaging 
server, but displayed to the user at the client system, in Figure 5 of the present 
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application. Therefore, because Rust does not even mention acquiring the approval of 
users at client systems to record, Rust does not teach each and every element of claims 
33, 39, and 45, and the claims should be allowed. 



Claims 34-36, 40-42, and 46-48 

Claims 34-36, which are representative in rejection and subject matter to claims 40-42 
and 46-48, respectively, read: 

34. (Currently Amended) The method for participating in a messaging 
session according to claim 29, said step of adjusting said output to 
distinguish a selection from among said plurality of message entries being 
recorded, further comprising the step of: 

adjusting , at said particular client system, a textual output 
characteristic of said selection from among said plurality of entries being 
recorded to distinguish [[a]] said selection from among said plurality of 
message entries being recorded from another unrecorded selection of 
said plurality of message entries . 

35. (Currently Amended) The method for participating in a messaging 
session according to claim 29, said step of adjusting said output to 
distinguish a selection from among said plurality of message entries being 
recorded, further comprising the step of: 

adjusting , at said particular client system, a graphical output 
characteristic of said selection from among said plurality of entries being 
recorded to distinguish [[a]] said selection from among said plurality of 
message entries being recorded from another unrecorded selection of 
said plurality of message entries . 

36. (Currently Amended) The method for participating in a messaging 
session according to claim 29, said step of adjusting said output to 
distinguish a selection from among said plurality of message entries being 
recorded, further comprising the step of: 

adjusting , at said particular client system, an audible output 
characteristic of said selection from among said plurality of entries being 
recorded to distinguish [[a]] said selection from among said plurality of 
message entries being recorded from another unrecorded selection of 
said plurality of message entries . 
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In the rejection of claims 34-36, the Examiner cites Rust, paragraphs 0047-0049 and 
0053-0054 as reading on the previously presented elements of claims 34-36, 40-42, 
and 46-48. [Office Action, p. 4, 6, 7-8] Paragraphs 0047-0049 of Rust describe that 
control server 140 may detect multiple presenter clients and record a separate log for 
each presenter client. Paragraphs 0053-0054 describe a playback client 150 that can 
select to view previously recorded collaborative web browsing sessions from control 
server 140. None of paragraphs 0047-0049 and 0053-0054, or any other portion of 
Rust, describes actually adjusting the output of only the selection of message entries 
separately being recorded by the messaging server. Further, none of paragraphs 0047- 
0049 and 0053-0054 refers to adjusting the textual, graphical or audio output of the 
selection of messages output at a client system to indicate that the messaging server is 
recording those messages. In contrast, claims 34-36, 40-42, and 46-48 describe that in 
addition to the messaging server recording a log of a selection of message entries, the 
output of that selection of message entries is adjusted at the client system, through 
adjusting one of the textual, graphical, or audible output of the selection of message 
entries. To clarify claims 34-36, 40-42, and 46-48 specifically teach adjusting the 
graphical, textual, or audio output of the selection of message entries separately being 
recording by the messaging server to be distinguished from unrecorded message 
entries, claims 34-36, 40-42 and 46-48 are amended as indicated. For example, claim 
34 is amended to include the element of adjusting, at said particular client system, a 
textual output characteristic of said selection from among said plurality of entries being 
recorded to distinguish said selection from among said plurality of message entries 
being recorded from another unrecorded selection of said plurality of message entries. 
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Lack of Obviousness under 35 USC § 103(a) 

Claims 1-4, 6-8, 10-13, 15-17, 19-22, 24-26, and 28 are not obvious under Schoof, II 
in view of Bvers 

Claims 1-4, 6-8, 10-13, 15-17, 19-22, 24-26, and 28 stand rejected under 35 
USC 103(a) as being unpatentable over Schoof, II (US Patent 5,440,624) in view of 
Byers et al. (US 6,987,841) (referred to herein as Byers). Applicants respectfully assert 
that claims 1-4, 6-8, 10-13, 15-17, 19-22, 24-26, and 28 are not obvious under Schoof II 
in view of Byers and therefore should be allowed. 



Claims 7, 11, and 20 



Independent method claim 1, which is representative of claims 11 and 20, reads 
as follows: 

1 . (Currently Amended) A method, in at least one server system for 
enabling at least one messaging session via an instant messaging 
channel through a network between at least a selection of a plurality of 
separate client systems communicatively connected to said network, for 
recording a messaging session, said method comprising the steps of: 

in response to receiving a request to record a messaging session at 
said server system, detecting a separate authorization level of each 
separate user from among said plurality of users participating in said 
messaging session via said plurality of separate client systems: 

determining a selection of users from among a plurality of users at 
said plurality of separate client systems each with said separate 
authorization level within a particular authorization requirement for said 
particular messaging session: 

submitting a separate approval request to each of said selection of 
said plurality of users: 

responsive to each of said selection of said plurality of users 
authorizing said request, recording a log of a requested selection of a 
plurality of message entries associated with said messaging session, 
separate from distributing said plurality of message entries to said 
selection of said plurality of separate client systems; and 

notifying [[a]] said plurality of users participating in said messaging 
session via said selection of said plurality of separate client systems of 
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said recording of said requested selection of said plurality of message 
entries. 

In the rejection of claim 1 , the Examiner states 

Schoof II discloses a method in at least one server system (i.e. 
conference controller 130) for enabling at least one messaging session 
(i.e. conference) via an instant messaging channel (i.e. path 102) through 
a network (i.e. network 100) between at least a selection of a plurality of 
separate client systems (i.e. terminals 1 05, 110, 115, 1 20, 1 25, and 1 30) 
communicatively connected to said networks (i.e. telephone network 20 
and LAN 13) for recording a messaging session, said method comprising 
the steps of (col. 5, lines 31-53 and col. 6, lines 5-32); 

in response to receiving a request to record a messaging session at 
said server system 130, recording a log (i.e. a archive record 440) of a 
requested selection of a plurality of message entries associated with said 
messaging session (i.e. all messages sent to the context controller are 
written to the archived record file; col. 13, lines 23-32), separate from 
distributing said plurality of message entries to said selection of said 
plurality of separate client systems (col. 13, lines 23-32 and lines 33-38); 
and 

notifying a plurality of users participating in said messaging session 
via said selection of said plurality of separate client systems of said 
recording of said requested selection of said plurality of message entries 
(col. 8, lines 4-15). 

Although Schoof II et al. disclose the invention substantially as 
claimed, Schoof II et al. are silent regarding notify a plurality of users in 
said messaging session via said selection of said plurality of separate 
client systems of said recording of said requested selection of said 
plurality of message entries. 

Byers et al. in an analogous art disclose a system utilized for 
recording an audio conference call. Byers et al. further discloses receiving 
a request from a communicating party to record the audio conference and 
receiving authorization to record the communication from the other parties 
participating in the conference (col. 3, lines 37-41 and col. 8, lines 9-27). 

Hence providing the request to record the audio conference as 
disclosed by Byers et al. would be desired in order to provide 
authenticated proof of the communication, identification of the 
communicating parties, authenticated copies of the recording, and notify 
other parties of the recorded communication (col. 2, lines 42-45 and col. 3, 
lines 37-41 and lines 65-67). 

Therefore, at the time of the invention, it would have been obvious 
to one of ordinary skill in the art to have modified the system of Schoof II 
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by sending a request to the telephone system from the conference 
participants to record the audio conference as disclosed by Byers et al in 
order to authenticate data associated with the recording and notify 
participants of the record communication. [Office Action, pp. 8-9] 

Regardless of whether the Examiner's previous assertions are correct, Applicants 
amend claims 1,11, and 20 and traverse the rejection of claims 1,11, and 20 in view of 
the amended claims. 

First, in establishing a prima facie case of obviousness under 103(a), the 
combined prior art references must teach or suggest all the claim limitations. In re 
Vaeck, 947 F.3d 488, 20 USPQ2d 1438 (Fed Cir. 1991). Applicants respectfully assert 
that Schoof II and Byers, separately or in combination, do not teach or suggest in_ 
response to receiving a request to record a messaging session at said server system , 
detecting a separate authorization level of each user participating in said messaging 
session via one of said plurality of separate client systems , determining a selection of 
users from among a plurality of users at said plurality of separate client systems each 
with said separate authorization level within a particular authorization requirement for 
said particular messaging session , or submitting a separate approval request to each of 
said selection of said plurality of users . 

Applicants note that in claims 3 and 4, which previously included the elements of 
"submitting a plurality of approval requests to a selection of said plurality of user 
participating in said messaging session", "controlling recording of said messaging 
session according to responses to said plurality of approval requests", in response to 
receiving a request to record said messaging session at said server system, 
determining authorization required for recording" and "only recording said log of said 
messaging session if said plurality of approval requests are received as required by said 
authorization", the Examiner cited Byers, col. 3, lines 38-41 and col. 8, lines 9-26 as 
reading on these elements. Col. 3, lines 38-41 of Byers read "Before making the 
recording, the system may receive from the second communicating party an 
authorization to record the communication. A response to that request may be included 
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in a recording record." In addition, col. 8, lines 9-26 of Byers describe that a second 
party may be prompted to press a button to agree to the recording. 

While Byers describes that during a telephone call, one call party may be 
requested to authorize recording of the call, Byers does not describe acquiring 
authorization if there were multiple parties to a call and also does not describe 
determining which of the multiple parties is required to give authorization for recording 
the call. In particular, neither Schoof II nor Byers, however, describes detecting an 
authorization level of each user participating in a messaging session, determining which 
selection of users are assigned an authorization level that meets the authorization 
requirement for the particular messaging session, and promoting that selection of users 
to authorize recording the messaging session. 

In contrast, claims 1,11, and 20 are amended to clearly teach a messaging 
server that facilitates a messaging session between multiple users as multiple client 
systems and at that messaging server, detecting a separate authorization level of each 
user participating in said messaging session via one of said plurality of separate client 
systems , determining a selection of users from among a plurality of users at said 
plurality of separate client systems each with said separate authorization level within a 
particular authorization requirement for said particular messaging session , and 
submitting a separate approval request to each of said selection of said plurality of 
users . Applicants submit that the specification supports the amendments throughout, 
and in particular in Figure 6, Figure 7, Figure 8, elements 96, 98, 100, 102, and 104 and 
paragraphs 0077-0082, and 0085-0086. Because Schoof II and Byers, separately or in 
combination, do not teach or suggest at least one element of claims 1,11, and 20, 
Applicants respectfully assert a prima facie case of obviousness is not established for 
claims 1,11, and 20 and respectfully request allowance of these claims as amended. 
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There is no suggestion or motivation to modify Schoof II by Byers 

To establish a prima facie case of obviousness, there must be a suggestion or 
motivation to modify the reference. In re Vaeck, 947 F.3d 488, 20 USPQ2d 1438, 1442 
(Fed Cir. 1991). The suggestion or motivation to modify Schoof II by Byers must come 
from the teachings the references, and the examiner must explicitly point to the teaching 
within the reference suggesting the proposed modification. Absent such a showing, the 
Examiner has impermissibly used "hindsight" occasioned by Appellants' own teaching to 
reject the claims. In re Surko, 1 1 F.3d 887, 42 USPQ2d 1476 (Fed. Cir. 1997); In re 
Vaeck, 947 F.3d 488, 20 USPQ2d 1438 (Fed Cir. 1991); In re Gorman, 933 F.2d 982, 
986, 18 USPQ2d 1885, 1888 (Fed. Cir. 1991); In re Bond, 910F.2d 831, 15USPQ2d 
1566 (Fed. Cir. 1990); In reLaskowski, 871 F.2d 115, 117, 10 USPQ2d 1397, 1398 
(Fed. Cir. 1989). Appellants respectfully assert that there is no motivation to modify 
Schoof II by Byers because the modification is merely a piecing together of references 
based on "hindsight" and not based in the teachings of the references. 

The Examiner notes that Schoof II does not teach or suggest notifying the users 
that selections of the message entries in a messaging session are being recorded. The 
Examiner states that "Byers et al. in an analogous art disclose a system utilized for 
recording an audio conference call. Byers et al. further discloses receiving a request 
from a communicating party to record the audio conference and receiving authorization 
to record the communication from the other parties participating in the conference (col. 
3, lines 37-41 and col. 8, lines 9-27)." [Office Action, p. 9] Applicants respectfully assert 
that if the Examiner is citing Schoof II as art that reads on a messaging server 
facilitating a messaging session via an instant messaging channel, then Byer's audio 
conference call system is not analogous art to Schoof II. As previously asserted with 
regard to claims 29, 37, and 43, for a proper interpretation of the claims, an instant 
messaging channel is interpreted in view of the ordinary meaning of the term, consistent 
with the specification, to be a channel for supporting real-time conversation via 
computer over the Internet. Applicants note that regardless of where the recording 
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service is located in Byers, the communication between a calling party and a called 

party is via a telephone call, not via an instant messaging channel. Art applicable to a 

telephone system is not automatically applicable to an instant messaging system. In 

addition, the Examiner's statement of the motivation for modification of Schoof II by 

Byers is as follows: 

Therefore, at the time of the invention, it would have been obvious to one 
of ordinary skill in the art to have modified the system of Schoof II by 
sending a request to the telephone system from the conference 
participants to record the audio conference as disclosed by Byers et al in 
order to authenticate data associated with the recording and notify 
participants of the record communication. [Office Action, p. 9] 

This statement as to the motivation for modification only refers to a motivation for 
modifying a telephone system; there is no indication that the relevant art as to claims 1 , 
1 1 , and 20 is an instant messaging system provided by a messaging server that 
facilitates messaging sessions via instant messaging channels. Thus, because Byers 
only suggests modification of a telephone service, to provide for recording of telephone 
calls and accessing recording authorization from call parties, but does not suggest 
modification of internet based communication services, such as an instant messaging 
service, there is no suggestion for modification of Schoof II by Byers to teach notifying 
said plurality of users participating in said messaging session via said selection of said 
plurality of separate client systems of said recording of said requested selection of said 
plurality of message entries . 

Claims 3, 4, 6-8, 10, 12, 13, 15-17, 19, 21, 22, 24-26 

Applicants respectfully assert that because claims 1,11, and 20 are not obvious under 
Schoof II in view of Byers, claims 3,4, 6-8, 10, 12, 13, 15-17, 19, 21,22, and 24-26, 
which are dependent upon independent claims 1,11, and 20, are also not obvious 
under Schoof II in view of Byers and should be allowed. 
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Claims 3, 12, and 21 

Claim 3, which is representative of claims 12 and 21, reads: 

3. (Currently Amended) The method for recording a messaging 
session according to claim 1 , said method further comprising the steps of: 

detecting, within said request to record said messaging session 
from a particular user from among said plurality of users, at least one 
criteria for selecting which of said plurality of message entries to record, 
wherein said at least one criteria specifies recording messages entered 
only by at least one other identified user from among said plurality of users 
participating in said messaging session: and 

only recording into said log said requested selection of said plurality 
of message entries entered by said at least one other identified user from 
among said plurality of users. 

subm i tt i ng a p l ura li ty of approva l r e qu e sts to a s ele ct i on of sa i d 

p l ura li ty of us e r part i c i pat i ng i n sa i d m e ssag i ng s e ss i on; and 

contro lli ng r e cord i ng of sa i d m e ssag i ng s e ss i on accord i ng to 

r e spons e s to sa i d p l ura li ty of approva l r e qu e sts. 

Applicants amend claims 3, 12, and 21 to teach selectively filtering out message entries 
to be recorded in a recording log based on the identity of the user entering the message 
entries. The specification of the present application, paragraphs 0063-0065 and Figure 
4, describes that a request to record the messaging session from a particular user may 
designate a criteria for selecting which message entries within a messaging session to 
record and that in particular, the criteria is the identifiers for those users message 
entries to record. 

Applicants respectfully assert that neither Schoof II nor Byers describes, once 
recording has started, selectively filtering the a selection of messages to be recorded 
into the log file of only those messages entered by a particular selection of users from 
among all the users participating in the messaging session. In addition, none of Schoof 
II or Byers, separately or in combination describes that a user request to record the 
messaging session specifies a selection of other users, from among all the users 
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participating in the messaging session, and that only messages from that selection of 
other users are to be recorded into the recording log. 

Therefore, because none of Schoof II or Byers teaches selective filtering of the 
messages recorded in a log once recording is triggered, neither Schoof II or Byers 
teaches detecting, within said request to record said messaging session from a 
particular user from among said plurality of users, at least one criteria for selecting 
which of said plurality of message entries to record, wherein said at least one criteria 
specifies recording messages entered only by at least one other identified user from 
among said plurality of users participating in said messaging session and only recording 
into said log said requested selection of said plurality of message entries entered by 
said at least one other identified user from among said plurality of users , and claims 3, 
12, and 21 should be allowed. 



Claims 4. 13. and 22 

Claim 4, which is representative of claims 13 and 22, reads: 

4. (Currently Amended) The method for recording a messaging 
session according to claim 1 [[3]], said method further comprising the 
steps of: 

responsive to determining a selection of users from among said 
plurality of users at said plurality of separate client systems each with said 
separate authorization level within a particular authorization requirement 
for said particular messaging session, detecting within a database at said 
messaging server at least one authorizing user of said selection of users 
that automatically provides approval for said recording request based on 
an identity of a particular user making said request to record said 
messaging session, wherein said authorizing user is removed from said 
selection of users required to respond to said approval request - 
i n r e spons e to r e c ei v i ng a r e qu e st to r e cord sa i d m e ssag i ng 
s e ss i on at sa i d s e rv e r syst e m, d e t e rm i n i ng author i zat i on r e qu i r e d for 
r e cord i ng; and 

on l y r e cord i ng sa i d l og of sa i d m e ssag i ng s e ss i on i f sa i d p l ura li ty of 

approva l r e qu e sts ar e r e c ei v e d as r e qu i r e d by sa i d author i zat i on. — 
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Applicants amend claims 4, 13, and 22 to teach detecting the selection of users 
required to authorize recording who have indicated in a database at the messaging 
server to automatically approve recording requests by particular users. The 
specification of the present application, paragraphs 0075-0076 and Figure 6, describes 
that each user may set preferences, stored by the messaging server, and that a 
preference may include a selection of users for which a particular user automatically 
agrees to authorize recording requests. 

As previously asserted, neither Schoof II nor Byers describes detecting only a 
selection of users required to authorize a recording request. In addition, neither Schoof 
II nor Byers describes detecting which of the selection of users automatically authorizes 
the recording based on the identity of the particular user requesting the recording. 
Therefore, because none of Schoof II or Byers teaches a messaging server with stored 
user preferences for the messaging server to automatically authorize, for a particular 
user, a recording request, neither Schoof II or Byers teaches responsive to determining 
a selection of users from among said plurality of users at said plurality of separate client 
systems each with said separate authorization level within a particular authorization 
requirement for said particular messaging session, detecting within a database at said 
messaging server at least one authorizing user of said selection of users that 
automatically provides approval for said recording request based on an identity of a 
particular user making said request to record said messaging session, wherein said 
authorizing user is removed from said selection of users required to respond to said 
approval request , and claims 4, 13, and 22 should be allowed. 

Claims 10, 19, and 28 

Claims 10, which is representative in rejection and subject matter to claims 19 and 28, 
reads: 

10. (Currently Amended) The method for recording a messaging 
session according to claim 1 , said step of notifying a plurality of users 
participating in said messaging session of said recording of said requested 
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selection of said plurality of message entries further comprising the steps 
of: 

accessing, at said messaging server, for each of said plurality of 
users, a separate selection of recording preferences identifying for each 
separate type of computing system a type of output requested for a 
recording indicator; and 

notifying each of said plurality of users by transmitting a separate 
recording indicator to each of said plurality of users at said plurality of 
client systems for output according said to a p l ura li ty of separate selection 
of recording preferences for each corr e spond i ng to a separate user from 
among said plurality of users. 

In the rejection of claim 10, as previously presented, the Examiner cited Byers, 
col. 8, lines 9-26 as reading on the claimed limitations. [Office Action, pp. 10-11] Byers, 
col. 8, lines 9-26 describes that during a phone call, a first party may request to record 
the call and a second party may be prompted to press a button to agree to the record. 
Byers does not teach that each user may set a different preference for how a recording 
indicator is to be output to that user. 

In contrast, claims 10, 19, and 28 teach that each user is notified of the recording 
through a recording indicator transmitted according to a separate set of recording 
preferences for each user. In addition, Applicants amend claims 10, 19, and 28 to 
clarify that the messaging server accesses, for each of the users, a separate selection 
of recording preferences identifying the type of output of a recording indicator requested 
by each user according to type of computing system and notifying each of the users 
about the recording by transmitting a separate recording indicator to each of the users 
at each of the client systems for output at the client systems according to the recording 
preference of the particular user at the client system. The specification, paragraph 0076 
and Figure 6, provide examples of a database for storing the recording preferences for 
each user at the messaging server, where the recording preferences indicate a type of 
output (e.g. text ref, audible, or graphical) depending on a type of computing system 
(e.g. home, portable, pda, or work) logged into by the user. 
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In conclusion, Applicants respectfully assert that because neither Schoof II or 
Byers, separately or in combination, teaches or suggests a database of user recording 
preferences at the messaging server, where the preference indicates a type of output 
for a recording indicator based on the type of computing system used by the user, 
Schoof II and Byers fail to teach at least one element of claims 10, 19 and 28, prima 
facie obviousness is not established, and the claims should be allowed. 

Claims 5, 9, 14, 18, 23, and 27 are not obvious under Schoof, II in view of Byers et 
al. and further in view of Fenton 

Claims 5, 9, 14, 18, 23, and 27 stand rejected under 35 USC 103(a) as being 
unpatentable over Schoof, II (US Patent 5,440,624) in view of Byers et al. (US 
6,987,841) and further in view of Fenton (US Patent 5,619,555). [Office Action, p. 15] 
Applicants respectfully assert that because claims 1,11, and 20 are not obvious under 
Schoof II in view of Byers, claims 5, 9, 14, 18, 23, and 27, which are dependent upon 
independent claims 1,11, and 20, are also not obvious under Schoof II in view of Byers 
and should be allowed. In addition, Applicants note that in the rejection on p. 15, claim 
19 is listed instead of claim 18; Applicants assume that this is a typographical error and 
that the Examiner intended to refer to claim 18, otherwise there were not be a rejection 
of claim 18 within the office action and claim 18 is associated with claims 9 and 27. 

In addition, as to claims 9, 18, and 27, Applicants respectfully assert that prima 

facie obviousness is not established for these claims because Schoof II in view of Byers 

and Fenton does not teach or suggest each and every element of claims 9, 1 8, and 27. 

Claim 9, which is representative of claims 18 and 27, reads: 

9. (Currently Amended) The method for recording a messaging 
session according to claim 1 , said method further comprising the step of: 

receiving said request to record from a user logged into said server 
system but not designated as a participant not part i c i pat i ng in said 
messaging session, wherein said user [[who]] is authorized to record said 
messaging session. 



Application No. 09/9 1 5,540 
Docket # AUS920010392US1 



54 



In establishing a prima facie case of obviousness under 103(a), the combined prior art 
references must teach or suggest all the claim limitations. In re Vaeck, 947 F.3d 488, 
20 USPQ2d 1 438 (Fed Cir. 1 991 ). In the rejection of claim 9 as previously presented, 
the Examiner cites Fenton, col. 3, lines 20-37 and col. 10, lines 1-35 as reading on the 
claimed limitations. [Office Action, p. 15] Fenton, col. 3, lines 20-37 describes that a 
user participating in an audio conference, while the audio conference is in progress, 
may select to enable or disable recording of the conference. Fenton col. 10, lines 1-35 
describes that in an audio conferencing system, a user participating in an audio 
conference meeting may start or stop recording the meeting. Fenton does not, 
however, describe that a user not participating in a messaging session may select to 
trigger the server system to record the messaging session. In contrast, claims 9, 18, 
and 27 clearly teach that the messaging server facilitating the messaging session 
receives the request to record from a user not participating in the messaging session, 
but authorized to record the messaging session. In addition, Applicants amend claims 
9, 18, and 27 to clarify that the request to record is received from a user logged into the 
server system but not designated as a participant in the messaging session. The 
specification, paragraphs 0078 and 0081 describes that each messaging session 
channel may include authorization requirements for recording a messaging session, 
including an authorization requirement that a user with a particular authorization level 
authorizes recording without the requirement that the user is a participating in the 
messaging session. Therefore, because Fenton does not teach or enable a non- 
participant user to select to record a messaging session, Schoof II, Byers and Fenton, 
separately or in combination, do not teach each and every elements of claims 9, 18, and 
27, prima facie obviousness is not established, and the claims should be allowed. 

Claims 49 and 51-54 are not obvious under Rust in view of Schoof, II 

Claims 49 and 51-54 stand rejected under 35 USC 103(a) as being unpatentable 
over Rust (US Pub 2004/0054728) in view of Schoof, II (US Patent 5,440,624). [Office 
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Action, p. 16] Applicants respectfully assert that prima facie obviousness is not 
established in the rejection of claims 49 and 51-54 under Rust in view of Schoof, II and 
therefore Applicants respectfully traverse the rejection of these claims. 
Claim 49 reads: 

49. (Currently Amended) A user interface at a client system for 
controlling recording of messaging sessions facilitated by a messaging 
server through at least one instant messaging channel via a network 
between a plurality of client systems, comprising: 

a selectable item for initiating recording by said messaging server 
of a log of a selection of message entries within a particular messaging 
session; and 

a changing textual display of a plurality of message entries within 
said particular messaging session for distinguishing said recorded 
selection of message entries within said particular messaging session 
from another unrecorded selection of said plurality of message entries 
within said particular messaging session . 

In the rejection of claim 49, the Examiner cites Rust, col. 9, lines 45-64 as reading on 
the element of a changing textual display of a plurality of message entries within said 
particular messaging session for distinguishing said recorded selection of message 
entries within said particular messaging session . Applicants note that Rust does not 
include a col. 9 and that the rejection of this element and other elements of claim 49 
appears to be based on col. 9, lines 45-64 of Fenton. Applicants note that col. 9, lines 
45-64 of Fenton describes that "meeting status information" can identify "whether the 
audio conference is currently being recorded by the system and whether voice 
announcements have been posted." Applicants respectfully note that even if the 
rejection is intended to refer to Fenton, Fenton merely describes that a user interface 
can be updated with an indicator of whether a recording is on or off. Fenton does not 
describe distinguishing, within the textual display of the message entries of a messaging 
session, those message entries being recorded. In addition, as previously noted with 
respect to claims 34-36, Rust does not teach or suggest changing the textual display of 
a plurality of message entries within a messaging session to distinguish the recorded 
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selection of message entries. Further, Applicants amend claim 49 to clarify that a 
textual display of the message entries themselves is adjusted to distinguish, at the client 
system, within a particular messaging session, a first selection of message entries 
recorded by the messaging server from a second selection of message entries not 
recorded by the messaging server. Therefore, because none of Rust, Schoof II, or 
Fenton, separately or in combination, teaches or suggests distinguishing recorded 
entries within a messaging session from non-recorded entries, a prima facie case of 
obviousness is not established and claim 49 should be allowed. 

Claims 51-54 

Applicants respectfully assert that because claim 49 is not obvious under Rust in view of 
Schoof II or Fenton, claims 51-54, which are dependent upon independent claim 49, are 
also not obvious under Rust in view of Schoof II or Fenton and should be allowed. 

Claim 50 is not obvious under Rust in view of Schoof, II and further in view of 
Bvers 



The rejection states that claims 49 and 51-54 stand rejected under 35 USC 
103(a) as being unpatentable over Rust (US Pub 2004/0054728) in view of Schoof, II 
(US Patent 5,440,624) and further in view of Byers et al (US 6,987,841) (referred to 
herein as Byers). [Office Action, p. 18] Applicants note, however, that the rejection 
based on Rust in view of Schoof II and further in view of Byers refers to claim 50. 
[Office Action, p. 18] Regardless of the teachings of Byers, however, Applicants 
respectfully assert that because prima facie obviousness is not established in claim 49, 
prima facie obviousness is also not established in claim 50, which is dependent upon 
claim 49 and Applicants respectfully request allowance of claim 50. 
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Conclusion 



In view of the foregoing, Applicant respectfully requests that a corrected election 
requirement be issued. If the Examiner feels that the pending claims could be allowed 
with minor changes, the Examiner is invited to telephone the undersigned to discuss an 
Examiner's Amendment. 

Respectfully submitted, 



AMY J. PATTILLO 
Registration No. 46,983 
P.O. BOX 161327 
AUSTIN, TEXAS 78716 
ATTORNEY FOR APPLICANTS 
Telephone: 512-402-9820 
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ON 8/7/2006 



